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A system and method for storing related data is disclosed, 
which receives a number of concepts related to the data to 
be stored, forms a number of relationships linking the 
concepts together, and which then represents the data in a 
way reflecting both the concepts and the relationships 
between the concepts. The relationships formed by the 
disclosed system include a number of independent aspects 
which add useful levels of meaning to the way the infor- 
mation is organized. One aspect of the relationships formed 
between concepts reflects predetermined application specific 
meanings that may be applied to individual relationships. 
Accordingly, the relationships provided in any specific 
embodiment of the disclosed system are defined to reflect a 
specific application of the system, such as, for example, a 
catalog service for receiving, storing, and publishing 
product-related information. 
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SYSTEM AND METHOD FOR 
REPRESENTING RELATED CONCEPTS 

CROSS REFERENCE TO RELATED 5 
APPLICATIONS 

N/A 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 10 

N/A 

BACKGROUND OF THE INVENTION 

Hie present invention relates generally to computer based J5 
information management systems, and more specifically to 
a system for representing, storing, and retrieving product 
information. 

In order to effectively market their products, product 
manufacturers must communicate product information to 20 
many parties, including product information aggregators 
such as on-line retailers or catalog suppliers, procurement 
partners within business to business procurement networks, 
prospective product purchasers ("consumers"), and others. A 
significant problem exists related to managing and storing 25 
large amounts of product information in a way that allows 
the information to be conveniently updated, while also 
enabling the information supplier to provide the information 
to multiple receiving parties in multiple formats, such that 
the information may be conveniently utilized for a variety of 30 
different, specific purposes. 

In some existing systems, an information aggregator may 
collect product information from one or more information 
suppliers, and then store the information using a relational 
database (RDBMS) system, such as those provided by 35 
various RDBMS suppliers. In these existing systems, the 
information aggregator predefines a number of tables and 
columns which define how the information is to be stored 
and accessed. Generally, product information for a given 
product occupies a row or "entry" within a predefined table, 40 
and the predefined columns define the searchable attributes 
of the populated database. Often, the set of predefined 
columns cannot be modified after tbe database is populated 
without a special operation that must be performed by a 
system administrator. It is difficult, however, to determine a 4s 
set of columns that are appropriate across different versions 
of a given product. It is even more difficult to determine a set 
of columns that are appropriate for a group of supposedly 
"related" products, which may be provided by different 
manufacturers. Additionally, it may be desirable to dynami- 50 
cally provide a specific "customized" information organiza- 
tion for a particular product, for example to reflect its 
"proprietary" features or some fundamental differences 
between it and competing products. These problems are 
exacerbated by the fact that significant product features or 55 
product characteristics may change over time, for example, 
due to new revisions or releases of the products. Moreover, 
for marketing purposes, different product manufacturers 
often seek to place emphasis on different features or product 
characteristics of their products with respect to competing so 
products. Existing RDBMS solutions further assume that 
ordering of the data they store is implicit in the data, as may 
be obtained by sorting the names of people alphabetically. 
However, in some cases, the information supplier may desire 
to specify a data ordering that is content independent. 65 

Some existing systems have responded to these complex 
problems by forcing large amounts of product information 



,588 Bl 

2 

into a single column, sometimes referred to as the "detailed 
description" of the product. In one example of such an 
approach, only the detailed description column and a part 
number column are provided as searchable attributes for 
each product entry. With this type of existing system, 
targeted searching to identify and/or compare product fea- 
tures is very difficult Even searching for matching text 
strings within the detailed description column is often 
ineffective, due to the use of different terminology for 
comparable features by different product manufacturers, and 
due to changes in terminology over time. 

When product information aggregators provide static, 
pre-formatted tables of product information with a prede- 
termined set of attribute columns, such predetermined col- 
umns cannot generally be dynamically controlled or 
configured, for example by the product manufacturers. Such 
systems also fail to provide a convenient mechanism for 
product information suppliers to dynamically modify indi- 
vidual product entries within the tables. In particular, while 
well understood features or product characteristics can be 
reflected to some extent by such predefined tables, no 
convenient mechanism is typically provided in existing 
systems for dynamically adding proprietary features or 
characteristics of a given product or product category to 
column definitions or headings. 

Accordingly it would be desirable to have a system for 
product information maintenance and storage which permits 
product information suppliers to conveniently update the 
information regarding particular products, as well as the way 
such information may be referenced and or retrieved. The 
system should further be capable of providing the informa- 
tion to a variety of publishing destinations, such as product 
aggregators, procurement partners, and/or consumers, in a 
way that enables effective product feature research and/or 
comparison. 

BRIEF SUMMARY OF THE INVENTION 

In accordance with the present invention, a system and 
method for storing related data is disclosed. The disclosed 
system treats all information it receives and stores as a 
number of discrete "concepts". The system receives a num- 
ber of concepts related to the data to be stored, such as 
product names, product categories, and/or product 
characteristics, forms a number of relationships linking the 
concepts together, and then represents the data in a way 
reflecting both the concepts and the relationships between 
the concepts. The relationships formed by the disclosed 
system include a number of independent aspects which add 
useful levels of meaning to the way the information is 
organized. One aspect of the relationships formed between 
concepts reflects application specific meanings that may be 
applied to individual relationships. Accordingly, the rela- 
tionships provided in any specific embodiment of the dis- 
closed system are defined to reflect a specific application of 
the system, such as, for example, a catalog service for 
receiving, storing, and publishing product-related informa- 
tion. 

In general, relationships may be formed to distinguish a 
subset of concepts from other concepts stored within a 
common data structure. In a tree data structure, relationships 
may be provided indicating that a number of concepts are 
distinguishable from other concepts within the same tree 
data structure, and which are stored as children of a common 
parent node. An ordering aspect of a relationship may also 
be provided indicating an ordering of child concepts under 
a common parent node within the tree. Because application 
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specific meanings provided by the relationships may be information model to describe one or more product charac- 

defined to support various specific applications, the dis- teristics that are applicable to products within a product 

closed system is applicable to any kind of information category. 

storage and retrieval application Accordingly, while the ^ « applic4 , ion specific meaning » of a relation- 

ulustrauye .embodiments .are described in connection with a s ship reflects a one of a pluralit y of predetermined 

product information application, the present invention is not ^ be UMdtM ^ , he re i a tionship, 

limited to such an application, and may be applied ad van- . L -T , 4 . , - • j . nil 

Ugeously to any data storage and retrieval apphcation which and # wl " ch are determined a priori with regard o use of the 

seeks to provide a meaningful representation of data. to n»™ *k to be stored. For example the set of 

T ... , ... 4 r , A . . r application specific meanings for a given application of 

In an illustrative embodiment for storage and retrieval oi in .. .. , j * i_ j c j * j • *• j 

, . . - ^ j* I j f , 10 the disclosed system may be denned at design time, and 

product information, the disclosed system receives and „ . , , J J . , . , ' . 

r . . , . ± * £ a* * ji j reflected by the resulting executable code implementing the 

stores concepts describing product information in a way that . r & 

enables information suppliers to conveniently and dynami- ^ 

cally add to and/or modify those stored concepts. The In an illustrative embodiment for storing product 
disclosed system may further be employed to organize the 15 information, the "application specific meaning" aspect of a 
information it receives in a way that reflects both shared relationship indicates certain meanings that are applicable to 
attributes and proprietary concepts related to various prod- ^ information model representing product information. A 
ucts. In an illustrative embodiment, a set of concepts is first fiist such application specific meaning would, for example, 
obtained, as well as associated concept names. Such con- indicate that the relationship reflects a "product category" 
cepts and associated names may, for example, originate in _ relationship between two concepts. Relationships may thus 
part or in whole a priori through a committee process in be . formcd indicating that a concept is a product category 
which various product manufacturers provide input and are vrthin another concept, such as a catalog tree. Further, the 
permitted to vote on a resulting shared concept set. Such application specific meaning aspect of a relationship may 
predetermined concepts are referred to herein as "shared" indicate that the relationship reflects "product" relationship 
concepts. "Private" concepts may also be obtained from « between the related concepts. The "product" application 
individual information providers. The resulting concept set specific meaning indicates that a particular concept repre- 
is then employed to generate the relationships used in the scnts a specific product with respect to another concept, 
disclosed system. In an illustrative embodiment, a unique which ma y be ' for example, a product category. A "product 
identifier is assigned to each of the concepts in the resulting characteristic" application specific meaning may be used to 
concept set. ^ ortn relationships indicating that a concept is a character- 
When the system has been "initialized" with the appro- 30 or f< ; aturc . ° f each P r ° duct a Product category, 
priate predetermined concept set, for example including a Relationships indicating the product characteristic' apph- 
number of shared concepts, a product information supplier catlon s P ccuic meaning may then be used to determine what 
can begin the process of entering product information for characteristics should be specified when product informa- 
oneormoreproducts.TheproductinformationsuppHermay 35 hon 15 **** entered for a P roduct a S wen P roduct 
optionally indicate a subset of a predetermined, shared category. 

concept set which should be applied to certain product Further for purposes of example, an illustrative "possible 

information it provides or has provided. The product infor- vahie " application specific meaning may be used to form 

mation supplier may further optionally provide one or more relationships indicating that a concept is one of potentially 

private concepts, for example associated with a private 40 several alternative values that may be associated with 

concept name, that are also to be applied to the storage another concept. Such a "possible value" relationship may 

organization and accessibility of certain associated product be used to prompt a user of the system with a number of 

information. In the case where one or more private concepts alternative values that may be input in association with a 

are provided, the disclosed system may also then assign a particular product feature or characteristic, 

unique identifier to each of the provided private concepts. 45 Another independent aspect of a relationship allows a data 

In order to store the product information, a set of rela- independent ordering to be specified between the two related 
tionships are formed which reflect an information model, concepts. For example, where a first object is indicated by a 
and which are determined in response to both the content first relationship to be a parent to a second concept, and by 
and context of the received concept set As a result, the a second relationship to be a parent of a third concept, the 
information model can be populated with product infbrma- 50 independent ordering aspects of the first and second rela- 
tion in a way that stores the provided concepts in a useful tionships may be used to indicate an ordering between the 
and meaningful way. The relationships linking various ones second and third concepts. Such an ordering may be used 
of the received concepts include a number of aspects, and when displaying the various concepts, for example to ensure 
impose application specific meanings on portions of an that the third concept is always displayed prior to or ahead 
information structure reflecting the information model. 55 °^ me second concept. 

A "relating concept" aspect of a relationship, allows for While a number of examples of apphcation specific 

dynamic modification of an information structure without meanings are provided herein with regard to an illustrative 

the need to modify a priori defined information, such as embodiment for maintaining product information in a cata- 

predetermined application specific meanings. Thus the log service, it will be recognized by one of ordinary skill in 

"relating concept" aspects of relationships are determined 60 the art that other application specific meanings may be 

based on explicit or implicit inputs received from users of generated for specific applications of the disclosed system, 

the disclosed system. The "relating concept" aspect of a and that the present invention is not limited to the illustrative 

relationship may be used to indicate that a relationship is embodiments described herein. 

applicable within a specified information structure, such as Further in an illustrative embodiment, the information 

a tree. The "relating concept" aspect of a relationship may 65 model reflecting the various concepts and relationships is 

also be used to indicate that a particular characteristic value used to generate an information structure for storing the 

is attached to a product, and further allows extension of an received product information. For purposes of illustration, 
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the illustrative information structure organizes the product connection 15. The publishing destinations 12 are shown 

information as an N-tree data structure, la such an including a web site 12a associated with product manufac- 

embodiment, the relationships between concepts addition- turer A 14, a partner network 12b for product manufacturer 

ally indicate a parent-child relationship between the two A, a web site 12c for an internet retailer A 13, a web site X 
concepts linked by the relationship, for example, as indi- 5 a business to business procurement network 12e, and a 

cated by way of the application specific meaning aspect of " brick ^ mortar " retailer X 12 /- The web site for internet 

the relationship. However, those skilled in the art will retailer A 13 is an example of a publishing destination that 

recognize that the invention is not limited to such an 15 a multi-source, product information aggregator, which 

embodiment, and any other suitable data structure may be Prides product information to .potential [customers regard- 
t Jx i J + ^- c . j*.„irig products from a variety of manufacturers and/or dis- 
employed. Moreover product information concepts > used to 10 ^ ^ ^ ^ x m ^ 

populate such a data structure may be indicated by, identified of a blishin destmation which distributes the information 
by, or received from a user through a variety of interfaces ided to it from ^ catal 10fl on a Umiled basi& , 

mcludmg World Wide Web-enabled, Internet browser based for example> internally via an intranet to display systems 
graphical user interfaces (GUIs). one or more storcSi 

In this way there is disclosed a system for product ^ Catalog server 106 is shown receiving product informa- 
information maintenance and storage which permits infor- tion from Internet retailer A 13, over an account connection 
mation suppliers to conveniently update information, for 17. The Internet retailer A 13, in turn, receives information 
example information regarding particular products, as well regarding a number of different products from product 
as the attributes which control how such information may be manufacturers 16, and publishes product information to the 
referenced and or retrieved. The disclosed system can be 20 web storefront 18. The web storefront 18 is an example of 
used to publish product information to a variety of publish- a publisher of product information, which is dedicated to 
ing destinations, in a way that enables the information to be providing product information to consumers regarding prod- 
conveniently formatted into a variety of specific catalogs, ucts mat can be purchased through Internet retailer A 13. 
and which enables different information consumers, such as Catalog server 10c is shown providing product informa- 
product information aggregators, to use the information in a 25 tion to a business to business procurement network 22 over 
variety of ways. m account connection 19. In this way, the business to 

business procurement network 22 receives information 

BRIEF DESCRIPTION OF THE SEVERAL regarding a variety of products from a number of supplier 

VIEWS OF THE DRAWING partners 20. The catalog server 10c is further shown pub- 

30 lishing product information to a number of procurement 

The invention will be more fully understood by reference partners 24, through the business to business procurement 

to the following detailed description of the invention in network 22. 

conjunction with the drawings, of which: As will be recognized by those skilled in the art, the 

FIG. 1 shows instances of an illustrative embodiment of catalog service server instances 10 may, for example, be 

the present invention operating over the Internet; 3S software application programs executing on one or more 

FIG. 2 is a flow chart showing steps performed in an hardware system platforms, on which are also executing 

illustrative embodiment of the present invention; World Wide Web enabling software, such as Internet Brows- 

FIG. 3 shows an illustrative information model; ers - Such server system hardware platforms, for example, 

FIG. 4 shows tables used in an illustrative embodiment to m f ? ^ dc a conventional processor memory and input/ 

define relationships between concepts; 40 output devices, as are found m generally available personal 

„ , r «.,.«. « i* * computers, server computers, mainframe computers, and/or 

FIG. 5 shows a screen display illustrating an "add prod- workstations . However, the present invention is not limited 

uct user input context; to such M em bodiment, and various alternative configura- 

FIG. 6 shows a screen display illustrating an "add product t i ons may be employed to provide the functionality 

characteristic value" user input context; and 4f described herein in association with the catalog service 

FIG. 7 shows a screen display illustrating an "add new server instances 10, including a configuration in which the 

product characteristic" user input context. catalog service server instances are co -located or co-resident 

™ c ™ rTrrTrkKT tuc with one or more of the software entities associated with 

DETAILED DESCRIFnON OF THE md/oT comroUed by pro duct information suppliers 14, 13, 
INVENTION 5q 2 Q f or publishing destinations 12, 18 and/or 24. 

As depicted in FIG. 1, an illustrative embodiment of the An example of the operation of the elements shown in 

disclosed system operates using World Wide Web (WWW) FIG. 1 is now described in connection with the steps shown 

technology over the Internet to provide communications in the flow chart of FIG. 2. At step 40 of FIG. 2, a number 

between software entities executing on a number of com- of application specific meanings, referred to for purposes of 

puter systems. The software entities in the illustrative 55 example as "relationship types", are defined or obtained 

embodiment of FIG. 1 are shown including a number of which may be employed to form relationships that impose 

catalog servers, shown for purposes of example as catalog useful meanings on a set of received concepts. For example, 

service server instances 10. Communications between the in an embodiment of the disclosed system for storing 

software entities in FIG. 1 may be provided using various product related information, "product category", "product", 

conventional communication protocols and message so "product characteristic", and "possible value" relationship 

formats, including those based on the HyperText Transfer types may be defined at step 40. In the example of FIG. 2 the 

Protocol (HTTP) and the Internet Protocol (IP)- set of relationship types defined at step 40 are determined a 

A first one of the catalog service server instances 10, priori to receipt of concepts from an information supplier, 

catalog server 10a, is shown operating to publish product based on the specific system requirements of the illustrative 

information to a number of publishing destinations 12. The 65 application. 

catalog server 10a is further shown receiving product infor- At step 42 of FIG. 2, a product information supplier 

mation from product manufacturer A 14 over an account establishes an account with a server instance of the disclosed 
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system, thereby setting up an associated account connection. with FIG. 4, or any other appropriate data structure. The 

A catalog server instance is created at step 42. The step of specific relationships that are formed may, for example, be 

establishing an account enables the information supplier to based on the input context in which the specific concepts to 

provide information to the catalog service server instance, be linked by a given relationship are received. Illustrative 

for subsequent publication to a number of publication des- 5 contexts which result in the formation of a specific relation- 

tinations. s yp between a number of concepts are described below with 

At step 44, a set of concepts are obtained by the catalog reference to FIGS. 5-7. The relationships formed at step 44 

service server instance (catalog server) created at step 42. As may be used to meaningfully organize and/or access the 

shown in FIGS . 5-7 and described below, concepts may be information stored by the disclosed system. Additionally, the 

entered manually. In addition to or as an alternative to the 10 representation of the information model may use an N-tree 

manual input process described with reference to FIGS. 5-7, organization to store the received product information in a 

in an illustrative embodiment, concepts can be imported into way tnat enables the product information to be accessed in 

the disclosed system using XML or other ASCII text file accordance with the information model, for example 

formats. XML allows textual information to be tagged with through the tables shown in FIG. 4. In such a case, the 

XML tags called "elements". XML elements may be used to 15 relationships between concepts would also establish a 

surround each piece of information related to a concept, as parent-child relationship between the linked concepts, 

shown below: jbe information supplied at step 44 provides product item 

<element>. . . information . . . </element> information that is used for later publication through the 

Different XML elements can be nested, allowing for catalog service server instance. For example, such item 

hierarchical structures, for example describing categories of 20 information describes the features and/or characteristics of 

products, in which each product has a number of character- one or more product items. In the illustrative embodiment, 

istics. Such an approach is illustrated below: the item information received at step 44 is treated as a 

<CD_players> number of concepts. For example, each product, product 

<product> feature or characteristic is treated as a separate concept for 

<name>Nano-Sonic CD-l</name> 25 purposes of storage and retrieval. 

<part_Number>xxx-xxx-xxx</part_Number> At step 46, the catalog service server instance created at 

<Hyper_Surround>18 channels</Hyper_ step 42 receives a number of publishing commands, for 

Surround> example from a user operating over an account connection 

</product> with an information supplier. In the illustrative embodiment 

VCD_players> 30 of FIG. 2, the information stored by the disclosed system is 

In an illustrative embodiment, the disclosed system reads published using a "push" model, in which a information 

XML files, matches the elements in the XML files to existing supplier user or program provides a publishing command 

concepts, and automatically creates relationships to repre- over an account connection, indicating that some or all of the 

sent the information in the XML file. product information stored by the system should be pub- 

The disclosed system may further publish XML files in a 35 lished to one or more indicated publishing destinations, 

format similar to the example above, based on the concepts Alternatively, a "pull" model may be employed, in which 

and relationships stored in the system. publishing destinations issue publishing requests in order to 

In an illustrative embodiment, a number of shared con- receive product information stored by the disclosed system, 
cepts may be initially determined by and/or provided from At step 48, the catalog service server instance references 
a product supplier committee, and then either entered into 40 those concepts necessary to satisfy the publishing com- 
the catalog server instance via an appropriate input or , mands received at step 46. As a result of step 48, the catalog 
configuration interface, or hard-coded directly into the cata- service server instance provides product information in a 
log server software. Each of the shared concepts, for number of different output formats 50 to a corresponding 
example, may be associated with a respective shared concept number of product information publishing destinations 52. 
name, which may also be input at step 44. Further at step 44, 45 The relationships formed between concepts in the dis- 
the product information supplier may optionally provide a closed system enable the stored product information to be 
set of private concepts and/or relationship types, for conveniently manipulated when it is published. For 
example which represent proprietary product categories, example, relationships may be associated within a common 
product characteristics, alternative possible values, and/or data structure, for example using a common "relating con- 
types of concept relationships relevant to, and available for 50 cept" relationship aspect for each of the associated relation- 
describing, products for which that product information ships. Such a shared "relating concept" can be used to 
supplier provides information. Such private concepts may organize the product information into subsets, and accord- 
each be associated with a private concept name, which may ingly to limit the published data for a particular publication 
also be input at step 44. The private concepts received at step destination to include only a subset of all stored products or 
44 are processed at step 44 by the catalog service server 55 product categories. The "product characteristic" application 
instance, by generating, modifying and/or augmenting a specific meaning can be used to indicate specific product 
number of data structures, such as the tables shown in FIG. characteristics to be published, or to arrange the hierarchy of 
4, in order to represent an information model, such as the the published data. Further, the ordering aspect of the 
information model shown in FIG. 3. While the illustrative relationships permit the stored information to be published 
embodiment is described in connection with the use of both 60 in a way reflecting a specified ordering, 
shared and private concepts, the present invention is not The elements of FIG. 3 illustrate an information model 
limited to such an embodiment, and alternative embodi- maintained by an embodiment of the disclosed system. Each 
ments may include only a single class of concepts, which of the elements shown in FIG. 3 represents a concept 
may be considered either shared or private. received from an information supplier, while each of the 

Hie relationships formed in step 44 between concepts 65 lines connecting the elements in FIG. 3 represents a rela- 

received in step 44 may be represented using entries in a tionship formed by the disclosed system between received 

number of tables, such as the tables described in connection concepts. The organization of the concept elements in FIG. 
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3, therefore, reflects the relationships formed by the dis- value 80a. Accordingly, the relationships illustrated by the 
closed system, for example in step 44 of FIG. 2. The lines connecting the concepts 80 to the MAKE concept 76a 
relationships represented by the lines connecting the con- express the "possible value" application specific meaning, 
cepts in FIG. 2 define both the parent-child relationships Similarly, a number of alternative characteristic possible 
between concepts, as well as providing additional applica- 5 values 82 are also shown associated with the "SACD" 
tion specific meanings, ordering information, and indication characteristic 78a of the compact disc player product cat- 
of relating concepts. For example, the relating concept egory 72a, including an "SACD+" possible value 82a. Thus, 
aspect of the relationships illustrated by lines connecting the the relationships illustrated by the lines connecting the 
categories 72 to the product tree root 1 70 may be the concepts 82 to the SACD concept 78a also express the 
product tree root 1 70 concept itself, indicating that the 10 "possible value" application specific meaning. These alter- 
categories 72 reside within the common structure shown in native possible values may be, for example, displayed to a 
FIG. 3. user that is inputting product information as potential alter- 
As shown in FIG. 3, a root concept 70 of a product tree, native values for selection or indication in connection with 
for example named "product tree 1", is shown related to a product information concepts being provided for a compact 
number of child concepts consisting of product categories 15 disc player. 

72. Accordingly, each of the lines connecting the root The information model illustrated by the root 70 of 
concept 70 of the product tree shown in FIG. 3 to each of the product tree 1, the items categories 72, and the relationships 
product categories 72 represents a relationship indicating the linking those concepts together in FIG. 3 may be represented 
"product category" application specific meaning. The prod- using a number of information structures, such as the tables 
uct category 72a is shown as a compact disc player product 20 shown in FIG. 4, that may further be populated with con- 
category, to be used to store information related to specific cepts describing actual, specific products. For example, the 
compact disc player products. The compact disc player compact disc item product category 72a could be populated 
product category 72a is shown related to a number of child with several compact disc item concepts, each correspond- 
concepts, including shared characteristic concepts 76, and ing to a specific compact disc player. As shown in FIG. 3, a 
potentially one or more private characteristic concepts 78. 25 sub-product category 86 of products related to the compact 
The lines connecting the compact players concept 72a to disc product category 72a is related to ("contains' 7 ) a number 
each of the shared and/or private characteristics, therefore, of "high end" compact disc players, and is specifically 
represent relationships expressing the "product characteris- related to the compact disc players product category by the 
tic" application specific meaning. Hie characteristics linked relationship 84. The relationship 84, for example, expresses 
to the compact disc player product category define a char- 30 the "product category" application specific meaning, 
acteristic set that applies to all product items under that The high end compact disc players product category 86 is 
product category. related to a number of other child concepts, shown as 
A number of pre-defined characteristic types may be including a number of specific compact disc player product 
employed to add further meaning to the way the disclosed concepts, for example model X 90, and model Y 92. The 
system stores the concepts it receives. Such pre-defined 35 product concepts 90 and 92 are in turn related to child 
characteristic types may be indicated by the value of one or concepts for actual values corresponding to the characteris- 
more flags stored in association with the relationship, for tics of the associated compact disc player products. The 
example, stored as a portion of the relationship type field characteristics of the product concepts 90 are defined with 
128, further described below in connection with FIG. 4. relation to the compact disc player product category 72a, 
Characteristics may be specified as "single-valued" when 40 such as MAKE, PART#, COLOR, etc. In this way, the 
they can only have one value (such as a weight), and as characteristics defined for the product category 72a become 
"multi-valued" when they can have multiple values (such as named attributes of the product concepts within that product 
a number of available colors). A "structured" characteristic category. Such attributes of a product concept can be related 
may be specified which can have a value selected from a to that product concept using relating concepts consisting of 
limited number of predefined values. An "unstructured" 45 characteristics for the category in which the product is 
characteristic, in contrast, is not limited to any predefined defined. For example, the relationship between the Model X 
value or values, and may be linked to a value indicating an 90 concept and the Make Value concept 90a, represented by 
arbitrary text string, file, image, or web page. Characteristics the line 91, would have a relating concept equal to the Make 
may further be defined as "inherited", such that they apply characteristic concept 76a. 

to all levels below the product category to which they are 50 A multi-function player sub-category 88 is further shown 

linked, or "non-inherited", such that they only apply at the as a child-concept related to the compact disc player product 

product category level. Non-inherited characteristics such as category through a relationship 85, which also expresses the 

this may be useful for providing product category descrip- "product category" application specific meaning. The multi- 

tions that only apply at one level. Characteristics may further function player product category concept 88 is shown 

be defined as "optional", meaning that they need not be filled 55 related to child-concepts consisting of the model Z compact 

in for each product, or "required", meaning that some disc player concept 94, as well as the model X compact disc 

indication, warning, or error message will be provided to a player concept 90, for example by relationships expressing 

user if they.are not provided with a value for a given product. the "product" application specific meaning. 
Additionally, characteristics may be defined as '"unique", FIG. 4 shows tables used to define relationships between 

indicating that only one product can have a given value for 60 concepts in an illustrative embodiment. A Concepts table 

that characteristic at one time, or "non-unique", indicating 100 includes a number of entries 108, each corresponding to 

that multiple products may have the same value for that a concept. The Concepts table 100 is shown including a 

characteristic. Unique ID column 102, a Name column 104, and an XML 

A number of child concepts, consisting of alternative Tag field 106. Each of the columns 102, 104 and 106 shown 

possible values 80, are shown related to the "MAKE" 65 in the Concepts table 100 are searchable attributes of the 

characteristic 76a of the compact disc player product cat- table. Accordingly, searches may be directed to the contents 

egory 72a, including a predefined "SSONY™" possible of individual columns in the table 100, in order to identify 
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entries matching certain search strings or values within one 
or more of those columns. 

In an illustrative embodiment, a translation copy of the 
concepts table is also maintained. Such a translation copy of 
the concepts table may, for example, be used to store 5 
corresponding natural language translations for one or more 
characteristics or aspects of each concept represented within 
the concepts table. For example, each entry in a translation 
copy of the concepts table 104 could be used to store a 
natural language translation of a concept name stored in the 10 
name field 104 of a corresponding entry within the concepts 
table 104. Each entry within such a translation copy of the 
concepts table 100 may, for example, be indexed using the 
same Unique ID value as may be used to index the corre- 
sponding entry in the concepts table 104. 15 

The Unique ID 102 for an entry is assigned by the 
disclosed system, and is unique across the complete concept 
set, including both shared and private concepts. The Name 
104 for an entry may be a private concept name or shared 
concept name provided by a product information supplier, 20 
and the XML Tag field 106 may be used to store or indicate 
the XML element name associated with the concept. 

In the embodiment shown in FIG. 4, the Concepts table 
entry 108a has a Unique ID of 10, a concept Name consist- 
ing of the string "Tree 1 Root", and corresponds to the 25 
product tree 1 root 70 shown in FIG. 3. In an alternative 
embodiment, the concept Name for table entry 108a could 
be equal to a name of a specific product information catalog. 
The Concepts table entry 108b has a Unique ID of 50, a 
concept Name of "CD Players", and corresponds to the 30 
compact disc player product category 72a shown in FIG. 3. 
The Concepts table entry 108c has a Unique ID of 5, a 
concept Name of "High End Compact Disc Players", and 
corresponds to the high end compact disc player product 
category 86 shown in FIG. 3. The Concepts table entry lOHd 35 
has a Unique ID of 7, a concept Name of "Multi-Function 
Players", and corresponds to the multi-function players 
product category 88 shown in FIG. 3. The Concepts table 
entry lOSe has a Unique ID of 90, a concept Name of 
"SONY", and corresponds to the "SONY" characteristic 40 
possible value 80a shown in FIG. 3. The Concepts table 
entry 108/ has a Unique ID of 17, a concept Name of 
"SACD+, and corresponds to the "SACD+" characteristic 
possible value 82a shown in FIG. 3. The Concepts table 
entry 108g has a Unique ID of 19, a concept Name of 45 
"MAKE", and corresponds to the characteristic "MAKE" 
76a shown in FIG. 3. The Concepts table entry lOSh has a 
Unique ID of 20, a concept Name of "SACD", and corre- 
sponds to characteristic 78a shown in FIG. 3. The Concepts 
table entry 108i has a Unique ID of 21, a concept Name of 50 
"MODEL X", and corresponds to the MODEL X item 90 
shown in FIG. 3. The Concepts table entry 108; has a Unique 
ID of 22, a concept Name of "MODEL Y", and corresponds 
to the MODEL Y item 92 shown in FIG. 3. The Concepts 
table entry lOSk has a Unique ID of U, a concept Name of 55 
"Make VaT, and corresponds to the Make Val value 90a 
shown in FIG. 3. 

The Relationships table 120 includes a number of entries 
122, each one of which defines a relationship between a 
subject concept whose unique concept ID is stored in the 60 
Subject field 124 of the entry, and an object concept whose 
unique concept ID is stored in the Object field 132 of the 
entry. For purposes of illustration, and in response to the 
application specific meaning indicated by the Relationship 
Type field 128, the entries 122 of the Relationships table 120 65 
may further establish a parent-child relationship between the 
concept indicated by the Subject field of the entry and the 
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concept indicated by the Object field of the entry. Which of 
the related concepts is considered the parent concept, and 
which is considered the child concept, is determined by the 
application specific meaning indicated by the Relationship 
Type field 128. Those skilled in the art will recognize that 
the parent concept could alternatively be stored by either the 
Object field or the Subject field of an entry. Through either 
approach, the relationships defined by the entries in the 
Relationship table 120 also define an N-tree data structure of 
concepts. 

In addition to any parent-child relationship that may be 
defined between the related concepts, each entry in the 
Relationships table 120 defines several independent aspects 
of the relationship linking the Subject and Object concepts. 
The aspects of a relationship for a subject/object concept 
pair are independently defined by values contained in the 
Relating Concept 126, Relationship Type 128, and Order 
130 fields of the associated entry in the Relationships table. 
The value of the Relating Concept field 126 may indicate 
whether the Subject and Object concepts are within a 
common information structure, for example, a tree. The 
Relating Concept field 126 may also indicate a characteristic 
concept of a product category, in order to link a specific 
value for that characteristic to a specific product within that 
product category, as shown in FIG. 3 by the relationship 
represented by line 91 between the Make Val concept 90a 
and the Model X product concept 90. 

In the example shown in FIG. 4, a number of the entries 
in the Relationships table 120 have a value of 10 in their 
Relating Concept field 126, indicating that they are within a 
common information structure identified by the concept 
having a Unique ID of 10, such as the tree illustrated by the 
information model shown in FIG. 3, which is identified by 
the concept corresponding to the product tree 1 root 70. In 
an embodiment in which the information is organized into 
one or more tree data structures, the value of the Relating 
Concept field 126 may be used to define a "tree" within 
which the relationship between the Subject and Object 
concepts of a Relationship table entry exists. 

The value of the Order field 130 in each of the entries of 
the relationship table 120 indicates an ordering aspect of the 
relationship between child concepts of a common parent 
concept For example, the entry 122g indicates an ordering 
value of "ORD A" for the relationship between the Subject 
concept having a Unique ID of 5, and the Object concept 
having a Unique ID of 21. The entry 122/ indicates an 
ordering value of "ORD_B" for the relationship between 
the Subject concept having a Unique ID of 5, and the Object 
concept having a Unique ED of 22. For purposes of example, 
the Relationship Type of the relationships indicated by the 
entries 122g and 122i indicates that the Object concepts are 
children of a common parent object, indicated by the shared 
Subject concept having a Unique ID value of 5. Using the 
Unique IDs in the Concepts table 100 as a key, the ordering 
values ORD__A and ORD__B indicate, for purposes of 
example, that the Model X product concept 21 should be 
displayed before the Model Y product concept 22. In this 
way, the ordering aspect of each relationship can be used to 
independently control which product characteristic, product, 
or product category is displayed first with respect to any 
other product characteristic, product or product category, 
having a common parent concept. This ordering between 
concepts may be utilized to emphasize certain categories, 
products, or product characteristics over others, for example, 
in order to display sale items prior to other items. 

The Relationship Type field 128 stores a value indicating 
one of multiple application specific meanings that apply to 
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the relationship between the Subject and Object concepts Compact Disc Players concept. As shown by entry 122/t, the 

defined by an entry of the Relationships table 120. In the concept having a Unique ID of 7 (Multi-Function Players) 

illustrative embodiment for storing product related has a "Product" application specific meaning associated with 

information, four Relationship Type field values are defined, its relationship (RT_J3) to the concept with Unique ID of 21 

each of which provides a specific, associated application 5 (Model X). Accordingly, Model X is a product within the 

specific meaning. For example, a first Relationship Type Multi-Function Players concept. 

field value RT_A indicates the "Product Category" appli- FIGS. 5-7 illustrate an interface for receiving concepts 
cation specific meaning, a Relationship Type field value into an embodiment of the disclosed system. FIG. 5 is a 
RT _J3 indicates the "Product" application specific meaning, screen display showing an "add product" user input context 
a Relationship Type field value RT_C indicates that "Prod- 10 within the Graphical User Interface (GUI) of an illustrative 
uct Characteristic" application specific meaning, and a Rela- embodiment. FIG. 5 illustrates steps taken by a user to add 
tionship Type field value RT_D indicates "Possible Value" a concept for a new product to the disclosed system. A user 
application specific meaning. While these illustrative appli- viewing the display shown in FIG. 5, and accordingly 
cation specific meanings are appropriate for the embodiment viewing a category entided "CD Players" 200, has clicked 
described with reference to FIG. 4, the disclosed system is 15 on the "Insert" button 202, which resulted in the display of 
not limited to these particular application specific meanings, the field 204. The field 204 is shown having been filled in by 
and other application specific meanings may be used as the user, for example with a product name "Nano-Sonic 
appropriate for other embodiments of the present invention. CD-I". In order to insert this product into the disclosed 
Additionally, while the independent aspects of a relationship system, the user then clicks on the "OK" button 208. The 
in the embodiment of FIG. 4 are defined by the contents of 20 system knows, from the input context shown in FIG. 5, that 
separate Relating Concept, Relationship Type, and Order the "Nano-Sonic CD-I" product concept being added should 
fields for each relationship, other configurations of fields be related to the CD Player 200 category, using a relation- 
may alternatively be used to impose the relationship aspects ship having a "product" application specific meaning aspect, 
and/or application specific meanings appropriate for other FIG. 6 shows the state of the illustrative GUI shown from 
specific applications of the disclosed system. It will also be 25 FIG. 5 following the user clicking on the "OK" button 208 
noted that in the disclosed embodiment of FIG. 4, each of FIG. 5. The screen display of FIG. 6 shows the details 
relationship is represented in a way that permits the Relating regarding the newly added "Nano-Sonic CD-I" product, 
Concept, Ordering, and application specific meanings to be including several fields for receiving values of different 
independently specified. characteristics of the newly added product, like "Part Num- 
As shown in FIG. 4, entry 122a indicates that the concept 30 ber" 220, "Marketing Text" 222, and "Product Image" 224. 
having Unique ID of 50 (Compact Disc Players) has a These fields can be filled in by the user, resulting in new 
relationship to the concept with Unique ID of 5 (High End values for each of the corresponding characteristics. These 
Compact Disc Players) indicating that High End Compact prompts for characteristic values are displayed, for example, 
Disc Players is a "Product Category" sub -category within because the characteristics either have been provided by the 
the Compact Disc Players concept. Entry 1226 indicates that 35 user to describe another product under the CD Players 
the concept having a Unique ID of 50 (Compact Disc category, or because the embodiment of the disclosed system 
Players) also is associated with the "Product Category" was loaded with them as shared concepts used for organizing 
application specific meaning in its relationship to the con- and describing audio equipment. 

cept with Unique ID of 7 (Multi-Function Players). FIG. 7 shows a screen display in which the user is defining 

Accordingly, Multi-Function Players is also represented as a 40 a new "Hyper-Surround" characteristic for the "Nano-Sonic 

"Product Category" sub-category within the Compact Disc CD-I", which did not previously exist in the system. In 

Players concept illustration of FIG. 7, the "Nano-Sonic CD-I" product has a 

Entry 122c indicates that the Model X concept (Unique value 230 of "18 channels" for the "Hyper Surround" 

ID of 21) is related to the Make Val concept (Unique ID of characteristic 232. FIG. 7 illustrates the ease with which new 

11) by a relationship in which the Relating Concept is the 45 concepts such as. new product characteristics for specific 

Make characteristic (Unique ID of 19). product categories can be created. 

Hie values in entry 122d indicate that the concept having Those skilled in the art should readily appreciate that the 

Unique ID of 50 (CompactDisc Players) has a "Product programs defining the functions of the disclosed system can 

Characteristic" application specific meaning in its relation- be delivered to a computer in many forms; including, but not 

ship (RT_C) to the concept with Unique ID of 19 (MAKE), so limited to: (a) information permanently stored on non- 

Accordingly, MAKE is a "Product Characteristic" for prod- writable storage media (e.g. read only memory devices 

ucts within the Compact Disc Players concept. within a computer such as ROM or CD-ROM disks readable 

As shown in entry 122e, the concept having a Unique ID by a computer I/O attachment); (b) information alterably 

of 19 (MAKE) has a "Possible Value" application specific stored on writable storage media (e.g. floppy disks and hard 

meaning associated with its relationship (RT_D) to the 55 drives); or (c) information conveyed to a computer through 

concept with Unique ID of 90 (SONY). Accordingly, SONY communication media for example using baseband signaling 

is a possible value for the MAKE concept. Similarly, as or broadband signaling techniques, including carrier wave 

shown in entry 122/, the concept having a Unique ID of 20 signaling techniques, such as over computer or telephone 

(SACD) has a "Possible Value" application specific meaning networks via a modem. In addition, while the disclosed 

associated with its relationship (RT_D) to the concept with 60 system may be embodied in computer software, the dis- 

Unique ID of 17 (SACD+). Accordingly, SACD+ is a closed system may alternatively be embodied in part or in 

potential value for the SACD concept. whole using hardware components such as Application 

Entry 122g shows that the concept having a Unique ID of Specific Integrated Circuits or other hardware, or some 

5 (High End Compact Disc Players) has a "Product" appli- combination of hardware components and software, 

cation specific meaning associated with its relationship 65 While the invention is described through the above exem- 

(RT_J3) to the concept having a Unique ID of 21 (Model X), plary embodiments, it will be understood by those of ordi- 

Accordingly, Model X is a product within the High End nary skill in the art that modification to and variation of the 
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illustrated embodiments may be made without departing 
from the inventive concepts herein disclosed. Accordingly, 
the invention should not be viewed as limited except by the 
scope and spirit of the appended claims. 

What is claimed is: 5 

1. A method for storing related data, comprising: 
establishing a plurality of predetermined application spe- 
cific meanings, wherein said application specific mean- 
ings include product category, product, product 
characteristic, and possible value meanings, and 10 
wherein each of said plurality of predetermined appli- 
cation specific meanings is associated with a corre- 
sponding input context; 

establishing, subsequent to said establishment of said 
plurality of predetermined application specific 15 
meanings, an account with an information provider; 

receiving a plurality of concepts from said information 
provider through said account; 

forming a plurality of relationships between pairs of said 
plurality of concepts, wherein each one of said rela- 
tionships indicates a first one of said plurality of 
concepts as a first related concept, a second one of said 
plurality of concepts as a second related concept, a third 
one of said plurality of concepts as a relating concept, ^ 
and one of said plurality of predetermined application 
specific meanings as an application specific meaning 
aspect, and wherein each of said application specific 
meanings indicated by corresponding ones of said 
relationships is selected from said plurality of applica- 3Q 
tion specific meanings responsive to an input context in 
which one of said pair of concepts between which said 
relationship is formed is received; and 

wherein said forming each of said plurality of relation- 
ships includes storing said relationship in an entry in a 35 
relationships table, such that said entry refers to said 
first related concept, said second related concept, and 
said relating concept, using corresponding ones, of a 
plurality of unique identifiers associated with respec- 
tive ones of said plurality of concepts, and storing 40 
indication of said application specific meaning aspect 
of said relationship in said entry. 

2. The method of claim 1, further comprising: 
storing a translation copy of said plurality of concepts, 

where each concept in said translation copy includes a 45 
natural language translation of an aspect of a corre- 
sponding one of said plurality of concepts. 

3. The method of claim 2, wherein said storing said 
natural language translation of said aspect of said corre- 
sponding one of said plurality of concepts comprises storing 50 
a natural language translation of a concept name associated 
with said corresponding one of said plurality of concepts. 

4. The method of claim 1, further comprising storing an 
associated programmatic representation for each one of said 
concepts in said plurality of concepts. 55 

5. The method of claim 4, wherein said storing of said 
programmatic representation comprises storing a standard, 
text-based computer readable format that is sharable across 
different computers. 

6. The method of claim 4, wherein said storing each one eo 
of said programmatic representations comprises storing an 
Extensible Markup Language (XML) representation of said 
associated one of said plurality of concepts. 

7. The method of claim 1, further comprising: 

forming an independent ordering aspect for each of a first 65 
one of said plurality of relationships and a second one 
of said plurality of relationships, wherein said first one 



of said plurality of relationships and said second one of 
said plurality of relationships have the same first related 
concept, and wherein said ordering aspect for each of 
said first one of said plurality of relationships and said 
second one of said plurality of relationships provides 
indication of an order between said second related 
concept of said first one of said plurality of relation- 
ships and said second related concept of said second 
one of said plurality of relationships. 

8. The method of claim 7 further comprising: 
forming an independent ordering aspect for each of a third 

one of said plurality of relationships and a fourth one of 
said plurality of relationships, wherein said third one of 
said relationships and said fourth one of said relation- 
ships have the same second related concept, and 
wherein said ordering aspect for each of said third one 
of said plurality of relationships and said fourth one of 
said plurality of relationships provides indication of an 
order between said first related concept of said third 
one of said plurality of relationships and said first 
related concept of said fourth one of said plurality of 
relationships. 

9. The method of claim 7, wherein said first one of said 
plurality of relationships and said second one of said plu- 
rality of relationships both have one of said plurality of 
predetermined application specific meanings as an applica- 
tion specific meaning aspect, and wherein said first related 
concept of said first one of said plurality of relationships is 
the same as said first related concept of said second one of 
said plurality of relationships, and wherein said one of said 
plurality of predetermined application specific meanings 
further indicates that said first one of said plurality of 
relationships is a parent concept to both said second related 
concept of said first one of said plurality of relationships, 
and said second related concept of said second one of said 
plurality of relationships. 

10. The method of claim 1, wherein said application 
specific meaning aspect of said relationship further indicates 
that said first one of said plurality of concepts is a parent 
concept to said second one of said plurality of concepts. 

11. The method of claim 1, wherein said receiving said 
plurality of concepts includes receiving at least one shared 
concept and at least one private concept 

12. The method of claim 1, wherein said input context 
comprises a graphical user interface (GUI) context. 

13. The method of claim 1, wherein said input context 
comprises a context within an import file, and wherein said 
context within said import file is defined by one or more 
tags. 

14. The method of claim 1, wherein said input context 
comprises a position within an input stream. 

15. The method of claim 1, further comprising storing said 
plurality of concepts in a first, relatively low speed storage 
device, and storing said relationships table in a second, 
relatively high speed storage device. 

16. A system for storing related data, comprising: 
at least one processor; 

at least one memory, said memory storing a computer 
program executable on said at least one processor, said 
computer program operable to 

establish a plurality of predetermined application spe- 
cific meanings, wherein said application specific 
meanings include product category, product, product 
characteristic, and possible value meanings, and 
wherein each of said plurality of predetermined 
application specific meanings is associated with a 
corresponding input context; 



03/17/2004, EAST Version: 1.4.1 



US 6,519,588 Bl 



17 



18 



establish, subsequent to said establishment of said 
plurality of predetermined application specific 
meanings, an account with an information provider; 

receive a plurality of concepts from said information 
provider through said account; 

form a plurality of relationships between pairs of said 
plurality of concepts, wherein each one of said 
relationships indicates a first one of said plurality of 
concepts as a first related concept, a second one of 
said plurality of concepts as a second related 
concept, a third one of said plurality of concepts as 
a relating concept, and one of said plurality of 
predetermined application specific meanings as an 
application specific meaning aspect, and wherein 
each of said application specific meanings indicated 
by corresponding ones of said relationships is 
selected from said plurality of application specific 
meanings responsive to an input context in which 
one of said pair of concepts between which said 
relationship is formed is received; and 

wherein said computer program is operable to form 
each of said plurality of relationships includes by 
storing said relationship in an entry in a relationships 
table, such that said entry refers to said first related 
concept, said second related concept, and said relat- 
ing concept, using corresponding ones of a plurality 
of unique identifiers associated with respective ones 
of said plurality of concepts, and by storing indica- 
tion of said application specific meaning aspect of 
said relationship in said entry. 
17. A computer program product including a computer 
readable medium, said computer readable medium having a 
computer program stored thereon, said computer program 
comprising: 

program code for establishing a plurality of predeter- 
mined application specific meanings, wherein said 
application specific meanings include product category, 
product, product characteristic, and possible value 
meanings, and wherein each of said plurality of prede- 
termined application specific meanings is associated 
with a corresponding input context; 

program code for establishing, subsequent to said estab- 
lishment of said plurality of predetermined application 
specific meanings, an account with an information 
provider; 

program code for receiving a plurality of concepts from 
said information provider through said account; 

program code for forming a plurality of relationships 
between pairs of said plurality of concepts, wherein 50 
each one of said relationships indicates a first one of 
said plurality of concepts as a first related concept, a 
second one of said plurality of concepts as a second 
related concept, a third one of said plurality of concepts 
as a relating concept, and one of said plurality of 55 
predetermined application specific meanings as an 
application specific meaning aspect, and wherein each 
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of said application specific meanings indicated by 
corresponding ones of said relationships is selected 
from said plurality of application specific meanings 
responsive to an input context in which one of said pair 
of concepts between which said relationship is formed 
is received; and 

wherein said program code for forming each of said 
plurality of relationships includes program code for 
storing said relationship in an entry in a relationships 
table, such that said entry refers to said first related 
concept, said second related concept, and said relating 
concept, using corresponding ones of a plurality of 
unique identifiers associated with respective ones of 
said plurality of concepts, and storing indication of said 
application specific meaning aspect of said relationship 
in said entry. 

18. A system for storing related data, comprising: 

means for establishing a plurality of predetermined appli- 
cation specific meanings, wherein said application spe- 
cific meanings include product category, product, prod- 
uct characteristic, and possible value meanings, and 
wherein each of said plurality of predetermined appli- 
cation specific meanings is associated with a corre- 
sponding input context; 

means for establishing, subsequent to said establishment 
of said plurality of predetermined application specific 
meanings, an account with an information provider; 

means for receiving a plurality of concepts from said 
information provider through said account; 

means for forming a plurality of relationships between 
pairs of said plurality of concepts, wherein each one of 
said relationships indicates a first one of said plurality 
of concepts as a first related concept, a second one of 
said plurality of concepts as a second related concept, 
a third one of said plurality of concepts as a relating 
concept, and one of said plurality of predetermined 
application specific meanings as an application specific 
meaning aspect, and wherein each of said application 
specific meanings indicated by corresponding ones of 
said relationships is selected from said plurality of 
application specific meanings responsive to an input 
context in which one of said pair of concepts between 
which said relationship is formed is received; and 

wherein said means for forming each of said plurality of 
relationships includes means for storing said relation- 
ship in an entry in a relationships table, such that said 
entry refers to said first related concept, said second 
related concept, and said relating concept, using cor- 
responding ones of a plurality of unique identifiers 
associated with respective ones of said plurality of 
concepts, and storing indication of said application 
specific meaning aspect of said relationship in said 
entry. 
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